Is this intended to happen in original voxel space or in physical space?
My idea was to slice along physical axes (making it compatible also with any kind of transformed sources) and simply introduce translations by source.shape[axis]/ n_slices. The case of a source only being scaled to physical space and slicing happening in a source axis would then be a subset of that general slicing operation.

I don't quite understand what you mean. But scaling must happen in physical space, since we only get the transformed version of the source here. See line 73 and following for how the transformation is computed (and I haven't double checked if this is correct yet, since I first need to implement the infrastructure to read the shape and transformation from the source metadata (i.e. bdv.xml or ome.zarr), which might be on s3)

Yes, makes total sense. My thinking was immersed in what the MoBIE viewer would do (that should know the bounds of the source); I completely forgot that we are in a separate code world here 😆

Obviously the shape we will build on is voxel-based an then all transformations will apply (not just scaling since all rotations and shear will also mess up the source shape).

Sorry, too much MoBIE-usage in the last day...

:) No worries

So we will need to apply all existing transformations to the "shape" vector. The slicing step would then be np.dot(T_all,shape)[axis]/n.

I think applying the slicing function to a single ("mother") source would be perfectly fine. You could simply add the other sources to the grid view and its transforms later once they are generated.

This makes perfect sense, but I am not sure we need the axis parameter then. Wouldn't you always slice along the z axis? (w.r.t. the initial transformation of course)

Slicing across another axis would just mean rotate it s.t. this axis becomes z

Should I add another parameter to the function so that you can pass a list of transformations that's applied before the slicing?

Maybe you could even reference an existing view and "import" the sourceTransforms from there?

This makes perfect sense, but I am not sure we need the axis parameter then. Wouldn't you always slice along the z axis? (w.r.t. the initial transformation of course)

Yes, you would then add the extra rotation in case slicing another axis. Otherwise the grid will also not be in the xy plane. Probably referencing an existing view (that users can generate in MoBIE and export) would be indeed ideal here (and then we can ditch the axis parameter). The users probably don't care how the transforms look as long as the orientation matches with what they like to see.

Maybe you could even reference an existing view and "import" the sourceTransforms from there?

Ok, but I will create two functions for this, one that takes initial transforms and one that takes a reference view.
(Having both options in the same function would require some handling of precedence if both are given, and I want to avoid that)
(And the one that takes a reference view just calls the one with initial transforms internally)

This is the function for creating a slice grid without passing an initial reference view.

This is the function for creating a slice grid from an initial reference view